キャッシュ系プラグインの最強版「WP Fastest Cache」の存在を最近知って、新規で作成したペラサイトとかに導入してみると、いきなりGT METRIXでスコア100出したりと、その威力を体感してはいましたが、すでにある程度軌道に乗っているサイトへの導入には慎重になっていました。
だってキャッシュ系プラグインって何が起こるか分からなくて危ないですからね。。。
タイトルの通りですが、「Internal Server Error 500」に久しぶりに遭遇しました。
[ad#adtop]
今回はテスト環境でプラグインを試したので、あせらなくて良かったのですが、本番環境だったら冷や汗ものでした。
原因を詳細に調べたわけではないですが、たぶんGzip Compressionの機能を有効化したあたりじゃないかと思っています。
私はテスト環境としてローカルではなく、普通にレンタルサーバーを使用しているのですが、同じサーバーに格納している他サイトのテスト環境は全く影響しておらず、まさにプラグインを使用したサイトでだけ起こっていました。
Serverのログを調査しなさいみたいなエラーメッセージが出てたので、DBUGモードを有効化してログを吐き出そうとしましたが、そもそもInternal Server Error 500が出てしまっているので、ログ吐き出しまでいきませんでした。
※ちなみにDEBUGモードの有効かはWordpressインストールしたディレクトリ直下のwp-config.phpの75行目あたりにある
define(‘WP_DEBUG’, false);の記述をdefine(‘WP_DEBUG’, true);に変えるだけです。
これだけだとログ出力できないのでdefine(‘WP_DEBUG_LOG’, true);を1行下に書き足すと、wp-contentディレクトリ下にdebug.logというファイルが出力されます。正常であれば。。。
DB自体は影響ないはずなので、.htaccessあたりが怪しいと思って、バックアップをローカルにとって削除したらビンゴでした。無事、サイトは正常表示されるようになりました。
キャッシュ系プラグインがサイトの高速化処理するために.htaccessにガリガリと書き込むと予想はしていたのですが、中身見ると結構行数増えてました。
しかしこのままではトップページは無事表示されるのですが、個別記事を表示しようとするとURLが見つからない状態となりました。
さっさと対処法を書きますと、設定からパーマリンク設定で保存を一度実行することで、無事デフォルトの.htaccessが作成され、個別記事ページへ遷移できるようになりました。
この作業もたまたま、最近GoogleがAMPのことで騒いでいたので、AMPプラグインを試してみた際に知ったことでした。
どれか一つでも欠けてたらドツボにはまるところでしたが、5分くらいで解決できて良かったです。
同じ問題で冷や汗中の方いましたら、参考までに。
[ad]
カテゴリー